Mapping Your Corporate Geomorphology 


What's in a Map? 

Maps can tell us about our organizations, our 
projects, our teams, our technologies, what we do 
well, what we do poorly, and provide us ways to think 
about change. Maps also suppress things. Their 
utility derives from their ability to provide an abstract 
view of the world. Maps are a representation, a 
cutting, a sample of reality. 

A formal organizational map can tell us certain things 
about the formal structure of a company. These 
maps also leave significant details abstracted away. 
The goal of an organizational map is to show simply 
and directly who reports to whom officially. While 
they may bear little resemblance to reality, they still 
have utility for our companies. 

Maps are representations of and abstractions of a 
perceived reality. As such, it is important to 
remember that they are not the real object which 
they refer to; they are simply tools to think with. 
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Getting in the Trenches 

Maps are based upon perception. A map 
disconnected from observational data has very little 
utility. The first key to using maps to improve our 
organizations is to base them on observation. 
Without a foundation in empirical reality, our maps 
are of little use. 

Organizational change is often attempted without 
first examining current conditions. A desired ideal is 
simply posited. Maps should be based on careful 
observation and analysis to provide insight into how 
easy or difficult change may be. The implementation 
of change can also be facilitated by maps. 

Maps that have been particularly useful for game 
development examine communication channels, 
project assignments, asset pipelines, conventions, 
employee skills, staffing needs, and industry 
positioning. Maps based on observation can improve 
our understanding of internal, external, present, and 
future organizational trajectory. 
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An Example: A Pre-Production Art / Engineering Conflict 

The following is an example based on difficulties between an art and engineering team during 
the pre-production phase of a project. The lead technical artist, located at the site of turmoil, 
asked me for guidance. Rather nebulously, a problem had been identified and labeled 
"communication." Though it was part of the problem, it was not our fault-line. We collaborated, 
discussing both of our observations, and realized that the fault-line was actually based on 
disciplinary difference of understanding what makes the project tick. 

We identified four different ways in which the project was being viewed, and mapped them. 
Each represents different perspectives of the same problem and its subcoponents. They were 
separated by scale (left pair of images are higher scale and right are lower), and in content (art 
or code). We found that artists were typically interested in understanding the game in a way 
that favored artistic aspects (represented by the satellite images). Engineers were primarily 
concerned with implementation (represented by the road maps). 

One possible resolution would be to simply lay the maps on top of one another, making a 
hybrid. However, this would not be a helpful solution. Attempting to teach your artists about all 
of the engineering aspects and vice versa, would be both cumbersome and likely impossible. 
The utility of specialization is that they should not need to know everything the other knows. 
Different scales and content is useful. Homogeneity should not be the goal. 

The higher scale "engineering" map to the lower-left illustrates the viewpoint of the 
engineering lead. Based on the map, it is obvious that this person's greatest knowledge will be 
the overall functionality of a system. They will likely have less knowledge of the system's 
lowest level of functionality (represented by the lower scale "engineering" map to the upper- 
right). At the same time, nor will a lead artist have the details of lower scales. But these 
acknowledged differences are necessary for the project to come to completion. 

The solution was to encourage all parties to understand the utility and "correctness" of each 
interpretation. While engineers might control the flow of art assets into the game, artists 
wanted some information about why an engineer was saying "no." Engineers also needed to 
understand why artists were attempting to create certain effects or models. We encouraged 
both groups to understand the differences in their viewpoints and scales people were working 
at. This approach provided a new language for discussing future collaborations. 



Be Respectful of your Existing Maps 

The second key to successful use of maps is to 
seriously consider your existing conditions. 

Moving a team member from one team to another, 
hoping to gain the benefit of more manpower on a 
project, can be complicated by significant differences 
between the production pipelines of two groups, and 
the additional ramp-up necessary. Some existing 
limitations are so severe that they can dramatically 
complicate a project. However, if you are constantly 
observing, mapping, and thinking critically about 
these issues in your company, you are far more likely 
to be successful. 



It's About the Fault-Lines! 

An excellent use of maps is to understand the real 
world based limitations of organizations and how to 
positively influence change. 

The third key to using maps is to pay special 
attention to fault-lines. They can be numerous, and 
derive from diverse areas, disciplinary training, 
corporate position, personalities, communication 
styles, office layout, tool chains, or external 
competition. 

Experimenting with what and how you map your 
organization can reveal new fault-lines. 





CONVERGENT TRANSFORM DIVERGENT CONVERGENT 

PLATE BOUNDARy PLATE BOUNDARY PLATE BOUNDARY PLATE BOUNDARY 


CONTINENTAL RIFT ZONE 
(YOUNG PLATE BOUNDARY) 




Poster Session Time: 

Wednesday, March 7, 2007, 1 :00 - 2:00PM 

Primary Takeaways: 


1 . What (does our company look like? 

2. Why (does our company look this way? 

3. What are the consequences of this typology? 

4. How can we make our map better? 
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